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Intellectual Property Rights 
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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and 
Systems (SES). 

The present document is part 1 of a multi-part deliverable covering Regenerative Satellite Mesh - A (RSM-A) air 
interface MAC/SLC layer specification, as identified below: 

Part 1 : " General description ' ' ; 

Part 2: "MAC layer"; 
Pai-t 3: "SLC layer". 
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Scope 



The present document is an introduction to the SMAC/SLC layer specification for the TC-SES BSM Regenerative 
SatelHte Mesh - A (RSM-A) air interface family. In particular it contains the description of the overall network and 
SMAC/SLC protocol architecture of the BSM Regenerative Satellite Mesh - A (RSM-A) air interface as seen from the 
ST. It also describes the various interfaces between the ST and other network elements and the relation between the 
layers in the ST logical protocol architecture as are discussed in the present document as well as the interactions with 
other layers in the BSM Regenerative Satellite Mesh - A (RSM-A) protocol architecture. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Network Operations Control Centre (NOCC): centre that controls the access of the satelHte terminal to an IP 
network and also provides element management functions and control of the address resolution and resource 
management functionality 

satellite payload: part of the satellite that provides air interface functions 

NOTE: The satellite payload operates as a packet switch that provides direct unicast and multicast 
communication between STs at the link layer. 

Satellite Terminal (ST): terminal that is installed in the user premises 
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terrestrial host: entity on which application level programs are running 

NOTE: It may be connected directly to the Satellite Terminal or through one or more networks. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ACF Access Control Field 

ARP Address Resolution Protocol 

BoD Bandwidth-on-Demand 

BSM Broadband Satellite Multimedia 

CoS Class of Service 

CRC Cyclic Redundancy Check 

EDU Extended Data Unit 

ESN Equipment Serial Number 

GEO Geosynchronous Earth Orbit 

HVUL High Volume UpLink 

IP Internet Protocol 

LLDC Link Layer Data Confidentiality 

MAC Medium Access Control 

MGID Multicast Group IDentity 

MIP Management Information Packet 

NIP Network Information Packet 

NOCC Network Operations Control Centre 

O&M Operations and Maintenance 

PDS Packet Delivery Service 

PDU Protocol Data Unit 

PEP Performance Enhancing Proxy 

PHY PHYsical 

PLR Packet Loss Ratio 

PTO Packet Transmission Opportunity 

PTP Point-To-Point 

QoS Quality of Service 

RRM Radio Resource Management 

RSM Regenerative Satellite Mesh 

SAM Security Access Module 

SAP Service Access Point 

SAR Segmentation And Reassembly 

SDU Service Data Unit 

SI-SAP SatelHte Independent-SAP 

SLC Satellite Link Control 

SMAC Satellite Medium Access Control 

ST Satellite Terminal 

TCP Transmission Control Protocol 

TIP Transmission Information Packet 

UDP User Datagram Protocol 

UDTS User Data Transport Services 

ULPC UpLink Power Control 



4 Network definition and protocol architecture 

This clause provides a network architecture that captures the main semantics of the BSM Regenerative Satellite 
Mesh - A (RSM-A) system as well as a protocol architecture that provides a logical framework in which to partition the 
functionality performed by an ST. The network architecture describes the main network elements which interface with 
the ST and provides reference points and reference interfaces. The protocol architecture provides a means to decompose 
the ST overall functionality into individual procedures that take place over the different interfaces. The protocol 
architecture defines layers in association with procedures and protocols only. The sublayer definition, functionality and 
interaction are informative. The protocol and procedures defined herein are normative. 
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4.1 Regenerative Satellite IVIesh - A network architecture 



4.1.1 



Network elements 



Figure 4. 1 describes the RSM-A network architecture from the satellite terminal viewpoint and also provides the 
different interfaces as seen by the satellite terminal. Both external and internal interfaces are shown in the figure. Each 
of these interface points might translate to a reference point for integration verification and testing. 
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Figure 4.1 : RSM-A Network interfaces 

The network elements are described below. 

Network Operations Control Centre (NOCC): The NOCC controls the access of the satelUte terminal to an IP 
network and also provides element management functions and control of the address resolution and resource 
management functionality. 

Satellite payload: The satellite payload is the part of the satellite that provides air interface functions. The satellite 
payload operates as a packet switch that provides direct unicast and multicast communication between STs at the link 
layer. 

Satellite Terminal (ST): The ST is the terminal that is installed in the user premises. It offers an IP data transportation 
service over the satellite network. 

Terrestrial host: This is the entity on which application level programs are running. It may be connected directly to the 
Satellite Terminal or through one or more networks. It maintains an IP route to one or more STs and uses their services 
to transmit IP data over the satellite network to destination IP hosts. 

Security Access Module (SAM): The security access module is an independent module physically resident in the 
Satellite Terminal. It contains authentication and identification data in a physically safe manner. The SAM is required 
by the ST to use the services of the RSM-A network. 

4.1 .2 Network interfaces 

The network interfaces are briefly described below. 

U Interface: This is the physical interface (the air interface) between a ST and the Satellite payload. All data 
transactions to and from the terminal including all user data to the destination ST, all management data to the NOCC 
and all signalling go over this interface. The same physical interface is used for both the BSM 1.5 and 1.6 interfaces [4]. 

N Interface: This is a logical interface between the ST and NOCC for transaction of management and signalling data 
between a ST and the NOCC. 

P Interface: This is a logical interface between two STs for transaction of peer layer signalling traffic and user data 
traffic. 

T Interface: This is the physical interface between the ST and the hosts. Multiple hosts can be connected to a single 
ST. The same physical interface is used for both the BSM 1.2 and 1. 10 interfaces [4]. 
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4.2 ST functional description 



The Satellite Terminal performs certain functions with regards to the host terminals and the network. These can be 
broadly categorized as described in the subsequent clauses. 

4.2.1 Network access control functions 

The ST shall perform a number of functions in order to access the network and use its resources to provide a data path 
to a host. The functions are categorized as: 

• Registration is the function whereby an individual ST is made a part of the RSM-A network when it is 
powered on for the first time or after an explicit deregistration operation. 

• Authentication and Authorization is the function whereby the network authenticates the ST and determines 
the amount and category of services that it is entitled to. 

• Admission control is the function whereby the ST admits user data into the system and calculates the QoS to 
be associated with these user data and the appropriate combination of network resources required to provide 
this QoS. 

• Network access is the function whereby an individual ST accesses specific radio resources as per requirement 
and subscription. 

• Usage tracking and charging is the function whereby the system tracks the usage each ST has made of the 
radio resources and converts it to charging information. 

4.2.2 Packet routing and transfer functions 

The ST shall perform a number of functions in order to transfer the user packets over the RSM-A network to the correct 
endpoint. The functions are categorized as: 

• Identification and Classification is the function whereby the ST classifies packets from a user port and 
assigns QoS parameters to each packet. 

• Routing is the function whereby the ST determines the next node in the network to which the packet stream 
must be forwarded in order for it to reach its final destination. This may be another terrestrial route, an egress 
ST or a gateway ST (in a dual-satelUte network or multi-hop route). 

• Address Resolution is the function whereby the ST determines the MAC address of the next node that has 
been determined by the routing function. 

• Compression is the function whereby the ST optimizes radio path capacity by performing lossless 
compression of the SDU. 

• Ciphering is the function whereby the ST protects the user data from eavesdropping and other security issues. 

4.2.3 Radio Resource Management functions 

The ST shall manage radio resources that it can use so as to protect the network and make the best use of its resources. 
The Radio Resource Management functions are identified as follows: 

• Radio path management is the function whereby the ST acquires and manages the physical radio paths that it 
can use, both dedicated and contention mode for its data transmission purposes in a manner which is compliant 
to the network configuration and rules and also to the QoS levels of the data that is going to be transferred over 
the system. 

• Radio path transfer is the function whereby the ST forwards packets over the radio path. This function must 
be able to manage the following: 

Medium Access Control. 

Packet multiplexing over common or shared channels. 
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Packet classification within the ST. 
Error detection and correction (optional). 
Flow control procedures. 

4.2.4 Network management functions 

Network management functions are those that the ST executes for maintaining the Operations and Maintenance (O&M) 
requirements of the network. Some examples are configuration and download, performance reporting, alarm reporting, 
etc. 

4.3 ST operational states 

The ST has different categories of operational states, the port-level state and the ST-level state. Conceptually, the ST 
offers services to the end-user through its ports. Thus the state of the port determines whether it can offer a specific 
function to the networks connected to that port. There is also a main state associated with the ST system as a whole. 
This determines, for example, whether the ST can contact the network, whether the ST has transmit/receive capability, 
whether the ST is configured, etc. Each ST-level state is characterized by the functions the ST has to perform to reach 
that state, the functions (if any) it has to perform while in that state, and finally the services that it can offer while in that 
state. The association between the ST states and the port states are also specified below. 

4.3.1 ST level states 
4.3.1 .1 ST state description 

There are three states for the entire ST at any given time. These states are shown in figure 4.2. 

• DEREGISTERED: In this state the ST is not registered with the satellite system. This state has five substates. 

IDLE: This is the initial substate of the ST after purchasing and installation. No services are available at 
this time. The ST is incapable of transmission or reception. 

RECEIVE: This is the substate of the ST after it has been installed with its antenna pointed correctly 
and its uplink polarization set correctly. It is able to receive the satellite beacon signal after powering on. 
The ST has performed cell and microcell selection and has determined the downlink destination ID, 
which it monitors for system information. At this point, the ST can receive system information and 
general data transmitted to it, but has no transmit capability. The ST is required to monitor the system 
information to determine whether it is required to upgrade its commissioning software to the appropriate 
software version. In case it does, it waits for the next round of transmission of the commissioning 
software from the network. Since the ST has no transmit capability, it passively obtains the 
commissioning software. In case of an error, it has to wait for the next round of transmission to recover. 

COMMISSIONED: In this substate the ST has enough information to start the registering process. It is 
still not an addressable entity. The commissioning software resident in the ST has been determined to be 
of the correct compatibility level. The ST has basic network access and transmission capability, but it is 
prohibited from carrying user-traffic. 

BARRED-GROUP: In this substate, the ST shall not transmit but shall continue to receive the beacon 
and all system information. The ST shall enter this substate upon receiving a command from the NOCC. 
The ST may leave this substate either upon receiving a command from the NOCC, which bars a group to 
which the individual ST belongs, or upon timer expiry as per clause 4.3.1.3. 

BARRED-IND: In this substate, the ST shall not transmit but shall continue to receive the beacon and 
all system information. The ST shall enter this substate upon receiving a command from the NOCC. The 
ST shall only leave this substate upon receiving a command from the NOCC, which bars the individual 
ST, as per clause 4.3. 1.3. 

• REGISTRATION INITIATED: In this state the ST is attempting to register with the satellite system. This 
state has no substates. 
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• REGISTERED: This is the state after the ST has successfully completed the registration and authentication 
process. This state has nine substates. 

RECONFIGURATION: In this substate the ST carries out three subtasks, software reconciliation, 
profile configuration and security key updating. No data services are available in this substate. The ST 
enters this state when powered-on. 

ACTIVE: In this substate the ST has reconciled its software versions, has valid configured profiles and 
updated security keys. The ST can securely transfer management data to the network. All user data 
services are available. The ACTIVE substate has several on-going subtasks such as acquisition of system 
information. The ST shall provide a visual indication to the user when it is in this substate and shall 
provide a visual indication to the user when it is not in this substate. 

POWERED OFF: In this substate, the ST has been powered off from any REGISTERED substate. 

NOLINK: This is a substate of the REGISTERED state whereby the ST loses physical connectivity to 
the network. User services are not available in this state. The ST shall reset the value of "current FTP slot 
number" to "2" until it requires a valid value in a Transmission Information Packet (TIP) message. 

BARRED-GROUP: In this substate, the ST shall not transmit but shall continue to receive the beacon 
and all system information. The ST shall enter this substate upon receiving a command from the NOCC. 
The ST may leave this substate either upon receiving a command from the NOCC or upon timer expiry 
as per clause 4.3.1.3. 

BARRED-IND: In this substate, the ST shall not transmit but shall continue to receive the beacon and 
all system information. The ST shall enter this substate upon receiving a command from the NOCC. The 
ST shall only leave this substate upon receiving a command from the NOCC as per clause 4.3.1.3. 

SUSPENDED: In this substate the ST shall not transmit user data but shall be able to transmit 
management signalling, including performance of diagnostic test messages. The ST shall only enter and 
leave this state upon command from the NOCC. 

MAINTENANCE: In this substate, the ST shall not transmit user data but shall respond to management 
signalling, including performance of diagnostic testing but shall not initiate unsolicited management 
signalling such as status, performance, and alarms reporting. The ST shall only enter and leave this state 
upon comment from the NOCC as per clause 4.3.2.1. 

OUT-OF-SERVICE: In this substate, the ST shall not transmit user data but shall respond to 
management signalling, excluding the performance of diagnostic testing but shall not initiate unsolicited 
management signalling such as status, performance, and alarms reporting. The ST shall only enter and 
leave this state upon command from the NOCC as per clause 4.3.2.1. 

NOTE: User data is only allowed in the Registered State/ Active substate. User data in this context includes IP 
layer diagnostics but does not include ST-NOCC management signalling that is at IP layer. 

4.3.1 .2 State transitions relative to system information reception 

An ST shall not transmit in any state except Registered, Substate Active, unless all system information including TIP, 
NIP, indirect MIP and direct MIP is current. This requirement implies that the ST cannot proceed from state 
Deregistered, Substate Commissioned to state Registration initiated or from state Registered, substate reconfiguration to 
state registered, substate active, unless all system information is current. 

The ST shall not transmit in state registered, substate active if TIP, NIP and indirect MIP are not current but may be 
able to transmit indefinitely without reception of direct MIP. In this substate, the ST shall use last received 
configuration parameters. 

4.3.1 .3 ST transmission barring 

The NOCC may enable and disable ST transmission via an Indirect or Direct MIP. Disabling transmission is called 
"barring" Barring may be applied to an individual ST specified by the ST Equipment Serial Number (ESN) or barring 
may be applied to a group of STs within a scope specified by the NOCC. Scopes for group barring include: a microcell, 
a geographic region specified by latitude and longitude coordinates, or a range of ST ESNs. 
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Group barring by microcell is done via the Indirect MIP. Other group barring scopes are specified via a Direct MIP. 
Individual barring is applied by a different Direct MIP. At any time, an ST may fall within the scope of one or more 
barred groups and/or may be individually barred. 

If an ST detects that it is within the scope of a barred group it transitions to the BARRED-GROUP substate. On the 
transition, the ST shall set a 5 minute timer. The ST shall exit the BARRED-GROUP substate upon receipt of an 
explicit indication from the NOCC that the group(s) is no longer barred or upon timer expiry. The timer is required for 
barring by Direct MIP but optional for barring by Indirect MIP. 

If an ST transitions to B ARRED-IND substate, it shall only exit this state upon receipt of an explicit command from the 
NOCC to do so. 

If an ST is individually barred and also belongs within the scope of a barred group, it shall transition to the 
BARRED-IND substate. 
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Figure 4.2: Network Access State Transition Diagram 
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4.3.2 Port level states 

An ST port is defined to be a virtual port instance of the SI-SAP. 

4.3.2.1 State description 

Each ST port has a state variable associated with it which can be in one of three different states. The state of a given ST 
port is independent of the state of other ports in the same ST but is tied to the current state of the ST. 
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Figure 4.3: ST port state transition diagram 

• READY: In this state, the port may offer services to the networks connected to it directly, if there is a valid 
profile existing for that port. The services available are listed below. The ST port can be in READY only if the 
ST state is NA_ACTIVE (state = REGISTERED; substate = ACTIVE). 

• MAINTENANCE: The ST port goes into this state on direct command from the NOCC. In this state it can 
still do connection setup/teardown, routing etc, but is prohibited from advertising these services to the local 
networks or to other STs. This state is to be used for diagnostic purposes only. 

• OUT-OF-SERVICE: An ST port goes into out-of-service state when the ST overall goes out of the active 
state or into one of the inactive substates of the active state or due to failure/deconfiguration of the port itself. 
In this state, the ST does not provide any services to either a local user or a remote ST. 

4.3.2.2 Port level services 

• Packet Transit: The service of delivering packets over the RSM-A system to other networks with/without 
QoS guarantees. 

• Routing: The service of identifying routes available over the RSM-A system and advertising them locally. 
Interaction with terrestrial routing protocols to allow seamless IP routing over the RSM-A system. 

• Connection setup: The service of setting up pre-scheduled/on-demand connections providing "virtual 
circuit-like" channels over the RSM-A system by negotiating with the network. 

• Multicast group setup: The service of setting up multicast groups for efficient point to multipoint 
communication over the RSM-A system. 
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4.4 ST protocol architecture 



4.4.1 Data plane architecture 

The RSM-A network architecture provides a spUt between Satellite dependent functions and Satellite independent 
functions. The purpose of this split is as follows: 

• separate the satellite specific aspects (i.e. a Ka-band GEO satellite with a packet switch) from the satellite 
independent higher layer. This separation is designed to permit future market developments, in particular IP 
enhancements; 

• provide flexibility for the addition of more complex market segment-based solutions (e.g. PEPs and 
Application Gateways). 

With some exceptions, functions in a satellite terminal can be conceptually categorized as link-specific and 
link-non-specific. RSM-A provides an interface to its transport core that is common for all network services, 
applications, and market segments. This interface is termed the Satellite Independent-Service Access Point (SI-SAP). 

In the OSI layering model, the SI-SAP is positioned between the link and network layers. With the SI-SAP so 
positioned, elements above the SI-SAP can, and indeed should, be designed without specific knowledge of the 
supporting link layer. Hence the introduction of the SI-SAP into the system design affords the following benefits: 

• Elements above the SI-SAP can be ported with greater ease to new satellite systems. 

• Extensibility to support new higher-layer functionalities without major re-engineering of existing designs. 

This clause describes the user data transmission plane in the RSM-A ST. The functions of the various layers and the 
various SAPs are described below. 

The architecture for the baseline ST configurations is shown in figure 4.4. The RSM-A Core Layers consist of the SLC, 
MAC and PHY layers. The IP Adaptation layers include the IP Plus Layer and the Transport Layer Performance 
Enhancing Proxies (PEP). 
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Figure 4.4: Simplified general RSM-A User Data Protocol reference architecture 

4.4.2 CoS and related concepts 

Quality of Service (QoS) is the abstract notion of how well a particular sort of traffic is carried to its destination, 
relative to the needs of that traffic. Because, in general, different kinds of traffic have different QoS requirements, 
traffic is categorized into different Classes of Service (singular: CoS). Traffic of a given CoS may be carried in different 
ways with the goal of providing the appropriate QoS for such traffic. 
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In RSM-A the CoSes are directly supported by User Data Transport Services (singular: UDTS), which are general 
characterizations of how traffic is queued and sent. The specific method by which a RSM-A packet is sent is termed a 
Packet Delivery Service (PDS). The PDS selected for transmitting a packet is related to the UDTS of the associated data 
traffic, but not in a strictly one-to-one fashion. 

STs may operate in High Volume UpLink (HVUL) or Bandwidth-on-Demand (BoD) mode. Both modes of operation 
are described in BSM RSM-A SMAC/SLC Layer Specification TS 102 189-2 [3]. The association of these concepts is 
shown in figure 4.5 for BoD. The complete set of rules for mapping UDTS to PDS are given in BSM RSM-A 
SMAC/SLC Layer Specification TS 102 189-2 [3]. 
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Figure 4.5: CoS, UDTS and PDS relationships 



4.5 Layer-wise functional partitioning 

This clause gives the functional responsibilities for each layer. 

4.5.1 Data link layer 

The data link layer provides the actual transport service over the RSM-A network. It is divided into two sublayers. 
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4.5.1 .1 Satellite Link Control sublayer 

The Satellite Link Control (SLC) layer is the sublayer of the Data link layer that is responsible for transmission and 
reception of packets from one ST to the other. Two modes of delivery are defined, unack-mode and ack-mode. Support 
of ack-mode delivery mode is optional. 

The functional responsibilities of the SLC are: 

Generation of session ids and mapping incoming packets into the corresponding session. 

Encryption and decryption of specific SDUs for user to user data privacy or Link Layer Data Confidentiality 
(LLDC) and conditional access. 

Computation of an error detecting CRC. 

Construction of Extended Data Units (EDUs) from SDUs. 

Segmentation of EDUs into segments and attaching of appropriate SLC headers. At the receiving ST, the 
corresponding SLC entity has to reassemble application EDUs. 

Construction of SLC-packet data units (PDUs). 

4.5.1 .2 Satellite Medium Access Control sublayer 

The Satellite Medium Access Control (SMAC) layer controls the way the ST uses uplink resources. The uplink 
resources described here are a combination of contention channels and dedicated resources. The SMAC has the 
following responsibilities: 

• The SMAC examines the UDTS and priority of the SDU and maps the SDU to a Packet Delivery Service 
(PDS). 

• The SMAC creates a RSM-A packet by adding a MAC header to an SLC-PDU. 

• The SMAC layer shall mark drop-classes appropriately as indicated in the associated CoS Profile. 

• The SMAC operates on the basis of queues. For each PDS there may be one or more queues. Each RSM-A 
packet, on the basis of the PDS and internal configuration information is queued in one queue. In order to 
retain in-order delivery RSM-A packets may not be moved between queues, but the way they are serviced may 
vary. 

• The SMAC continuously executes the appropriate algorithm to get resources from the network. 

• The SMAC layer combines RSM-A packets into blocks and allocates slots for individual blocks. Blocks are 
passed to the transmission layer for burst building together with the slot information. The reverse process is 
done on the receive side. 

• The SMAC interacts with the SAM to generate the Access Control Field (ACE) function for all MAC blocks 
that are transmitted on the U interface. 

• On the receive side, the SMAC layer receives incoming RSM-A packets and discriminates them on the basis 
of the destination RSM-A address. Packets may use either the unicast destination address of any of the ST 
ports and/or certain Multicast Group IDentities (MGIDs). These MGIDs are a combination of pre-reserved 
MGIDs for NOCC to ST transmission (which have to be monitored at all times) and MGIDs used for user-user 
multicast transmission. 



4.5.2 Physical layer 



The physical layer is described in more detail in BSM RSM-A Physical Layer Specification TS 102 188-1 [ 

] and has the following functions. 

• The physical layer executes the initial acquisition and synchronization procedure with the network. 

• The physical layer builds bursts (modulation, coding and power control functions) and transmits them on 
particular slots and channels as instructed by SMAC. 
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• The physical layer receives incoming packets and passes them to the SMAC for filtering. 

• The physical layer does dead link detection. 

• The physical layer adjusts the uplink transmission power. 

4.6 Procedure definitions 

The clause below identifies and defines procedures to be used over the Air Interface. 

Various procedures are defined in the following clauses. The procedures described below are divided into idle mode 
procedures, transmission side procedures in active mode and receive side procedures in active mode. They are invoked 
at different layers of the ST network architecture as described. 

4.6.1 Procedures in idle mode 

4.6.1.1 System information reception 

The ST shall monitor all System Information broadcasts. System information packets include the following: 

• Transmission Information Packet (TIP) messages (see BSM RSM-A SMAC/SLC Layer Specification 
TS 102 189-2 [3]); 

• UpLink Power Control (ULPC) status messages (see BSM RSM-A SMAC/SLC Layer Specification 
TS 102 189-2 [3]); 

• Network Information Packets (NIP), including: 

bandwidth assignment messages (see BSM RSM-A SMAC/SLC Layer Specification TS 102 189-2 [3]); 

negative acknowledgement messages (see BSM RSM-A SMAC/SLC Layer Specification 
TS 102 189-2 [3]); 

dynamic contention channel assignment messages (see BSM RSM-A SMAC/SLC Layer Specification 
TS 102 189-2 [3]); and 

• Management Information Packets (MIP). 

The TIP, NIP and ULPC status messages are received by the MAC layer. Management information packets are 
delivered to the appropriate agent in the control plane. 

4.6.1 .2 Transfer and reception of management traffic 

Management packets may be transmitted either on the contention channel or on the traffic channel. This is a local 
decision of the Media Access control function. Some management traffic is transmitted in secure mode using a key that 
is provided by the NOCC as part of the registration process. 

4.6.1 .3 SLC session initiation on destination side 

The ST has an internal packet discrimination and demultiplexing function as part of the Relay function that maps 
incoming packets to particular sessions. When a packet is received that cannot be mapped to any session, it is the trigger 
to create a new local SLC session to receive these packets. Whether this session be associated with the user plane 
(i.e. user data) or with the management plane is determined by its IP and RSM-A destination address. Management 
plane traffic uses a fixed set of multicast group ids or the management IP address. 

4.6.2 Procedures - transmission side 

The following clause describes the main procedures on the transmission side to deliver IP packets from a source ST to 
the destination ST. 
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4.6.2.1 Address resolution 



Terrestrial packets are received in the ST and routed over the RSM-A system to their final destination. For each packet, 
based on the destination IP address, the transmitting ST must identify the remote ST SMAC address to deliver the 
packet to that it can reach its final destination. The process of identifying the destination SMAC address of the 
appropriate remote ST is called address resolution. This may be static, where the information is pre-loaded into the ST 
or dynamic. 

The route and address resolution step must be undertaken before the IP packet is delivered across the SI-SAP. If the 
information is not available in the local cache an address resolution is requested across the interface. The address 
resolution function maps a next hop IP address to the next-hop ST-port RSM-A destination address, if the next hop to 
that destination is available over the RSM-A system and allowed by Community of Interest restrictions. For the first 
access to resolve a next hop IP address, the ST may query the network directly to identify the mapping. In subsequent 
accesses, the ST caches the network reply internally in its address resolution table. The table may be updated as part of 
the address resolution function by sending a "Satellite ARP" to the network for an IP address that does not exist in its 
internal table. If an address resolution query is answered in the negative by the network, this answer must also be stored 
internally to prevent spurious queries to the network. 

4.6.2.2 Connection setup, modification, and release 

Connection setup is either invoked by a request across the SI-SAP (on-demand) or by the arrival of an internal timing 
trigger (scheduled). If a new connection has to be setup, the connection management entity is invoked to execute the 
required signalling and setup the connection with the NOCC. Once the connection is setup, this information is passed 
back across the SI-SAP to the classifier, which automatically creates the appropriate classification rules so as to map 
specific categories of packets to this connection. 

Once the connection is setup, signalling across the SI-SAP or another time trigger may request modifications which 
may result in further signalling with the NOCC. 

A connection may be deleted if there are no sessions using it, or, in the case of a scheduled fixed time connection, when 
the time is up. Connection release is normally ST initiated, but can be network initiated in certain scenarios. 

4.6.2.3 Segmentation and packetization 

This function is executed at the SLC level for each SLC entity. EDUs are segmented to fit into fixed-size RSM-A 
packets. 

4.6.2.4 Satellite Link Control session setup and teardown 

Data is transmitted from a transmitting ST to a receiving ST by the satellite link control layer in individual sessions. A 
session is started when a new set of data has to be transmitted from a given ST port to another port and there are no 
existing sessions of the same mode to the same destination ST/port combination. 

The SLC entity is a half -duplex entity that transfers packets in one direction. In acknowledged mode, it receives Acks 
and processes them to take care of Backward Error Correction. Support of the acknowledged mode is optional. 

SLC sessions may be released when the corresponding data stream terminates, or the session is inactive for a given 
period of time or due to internal protocol failure. There is no explicit signalling associated with SLC session termination 
other than in acknowledged mode. 

4.6.2.5 Bandwidth management - resource allocation and queue management 

The bandwidth management function takes packets from the SLC sub-layer and identifies the appropriate Packet 
Transmission Opportunity (PTO) to transmit these packets on. 

The bandwidth management function operates on the basis of queues. All outgoing packets are mapped into one of 
many queues, based on their destination and the associated UDTS. Each queue has an assigned PDS. Depending on the 
queue state for each PDS, the SMAC executes the appropriate protocol and to garner radio resources in the form of 
PTOs for transmitting the queue contents. When PTOs are available, the SMAC layer uses a defined algorithm to 
identify which queue is to be serviced on each particular PTO. 
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4.6.2.5.1 Rate transmissions 



The ST maintains queues on a per connection basis with an associated rate and flow-control information. Each 
connection that has been negotiated with the NOCC is mapped to one queue. 

4.6.2.5.2 Volume oriented uplink data channels 

The ST maintains queues for volume transmissions. The queues are on the basis of priorities and destination region. 
Packets are mapped into the appropriate queue when they are delivered from SLC to SMAC. 

4.6.2.5.3 Contention mode access 

Contention channels are available for use both for data transfer as well as for control signalling i.e. resource requests. 
The contention channels are broken up into pools for data transfer or for contention mode resource requests. These 
divisions are partially statically configured and partially dynamically indicated by the network. Some pools may be 
reserved for certain groups of STs. The SMAC layer manages access to these resources as per the rules given in BSM 
RSM-A SMAC/SLC Layer Specification TS 102 189-2 [3]. 

4.6.2.5.4 Persistent aloha 

This is a modification of the standard Slotted Aloha procedure whereby a single terminal can grab a slot in a frame or a 
set of frames using the Aloha protocol and then continue using it once every frame (or every set of frames) till it 
relinquishes the slot by not transmitting in this slot. This protocol is used for low-latency, low-volume 
periodic/quasi-periodic traffic such as TCP Ack packets. The initial slot acquisition is similar to the Slotted 
Aloha/Contention method-details are provided in BSM RSM-A SMAC/SLC Layer Specification TS 102 189-2 [3]. 

4.6.3 Procedures - reception side 

The following clause defines the behaviour of the ST at the Network level for data reception. 

4.6.3.1 Connection setup 

Connection setup takes place when the ST receives a Connection Create message from the network indicating that some 
other ST is trying to setup a connection. The Connection Manager makes the decision as to whether the connection is to 
be setup or not. Once the connection setup procedure is initiated and the connection is setup, the Connection Manager 
keeps track of the connection and invokes the appropriate procedures. 

4.6.3.2 Session initiation 

A new SLC session is initiated by receipt of a packet or a burst of packets from the network with no corresponding SLC 
session existing. The packets are received by the SMAC layer discrimination function. An SLC session is created if no 
new session exists. 

4.6.3.3 Reassembly 

The reassembly procedure reassembles RSM-A packets into SDUs. 

4.6.4 Power control 

The objective of the Uplink Power Control (ULPC) function is to control the power of each ST transmitter so that 
Ec/ (NoH- lo) for each channel is adequate to meet the Packet Loss Ratio (PLR) objectives. Fine power control is done 
for those advantaged terminals (those in the clear sky) such that their interference to the disadvantaged terminals (those 
in rain fade) would be minimum. The major portion of the ULPC process is distributed between the network and the 
ST. Each ST adjusts its uplink (U/L) transmit power per carrier frequency based on beacon power measurements and 
feedback in the form of response packets. The network is, therefore, responsible for maintaining a stable beacon signal 
over time, and for performing power measurements on U/L packets from the STs. 
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4.7 Security Access Module - functional description 

The SAM is the primary security component of a satellite terminal. Physically it is a secure chip embedded in the 
terminal. The SAM contains secret key material and authenticates every RSM-A packet sent out by the terminal by 
generating an Access Control Field the can be verified by other authorized components of the system. The SAM will 
only sign requests that are valid within the policies set forth for that particular ST. On the receive side it verifies that 
management messages are authentic messages from the NOCC. See BSM RSM-A SMAC/SLC Layer Specification 
TS 102 189-3 [5] for a complete description of this interface. 

The S AM's areas of responsibility to the RSM-A system are as follows: 

• Authentication. 

• Authorization protection. 

• Registration. 

• Usage audit. 
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Figure 4.6: Security function interactions between the SAIV! and the ST 



4.8 ST types 



The RSM-A system supports multiple types of STs. The different types of STs differ in terms of functions, bit-rates and 
capabilities; the table below describes the different types of STs. ST type (MAC mode) corresponds to ST power class 
(phy mode). See BSM RSM-A TS 102 188-5 [2] for EIRP and G/T requirements per power class. 



Type 


Supported carrier modes 
(required) 


MAC Mode supported 


Other special features 


1 


128kb/s, 512kb/s 


BoD (required) /HVUL (optional) 




2 


128kb/s, 512kb/s 


BoD (required) /HVUL (optional) 


Additional EIRP for adverse 
weather environments 


3 


512kb/s, 2Mb/s 


BoD (required) /HVUL (optional) 




4 


512kb/s, 2Mb/s 


BoD (required) /HVUL (required) 


Open interface for user platform 


5 


512kb/s, 2Mb/s, 16 Mb/s 


BoD (optional) /HVUL (required) 
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